home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20010306-20010921 / 000246_fdc@watsun.cc.columbia.edu_Thu Jul 5 17:43:36 EDT 2001.msg < prev    next >
Text File  |  2020-01-01  |  5KB  |  127 lines
  1. Article: 12571 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!watsun.cc.columbia.edu!fdc
  3. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: Any way to alter Kermit "quit" so I don't have to "kill?"
  6. Date: 5 Jul 2001 21:43:52 GMT
  7. Organization: Columbia University
  8. Lines: 110
  9. Message-ID: <9i2n2o$dgn$1@newsmaster.cc.columbia.edu>
  10. References: <h_417.5247$oa1.534611@newsread1.prod.itd.earthlink.net>
  11. NNTP-Posting-Host: watsun.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 994369432 13847 128.59.39.2 (5 Jul 2001 21:43:52 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 5 Jul 2001 21:43:52 GMT
  15. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:12571
  16.  
  17. In article <h_417.5247$oa1.534611@newsread1.prod.itd.earthlink.net>,
  18. Keith Doyle <keithuse@synco_pator.com> wrote:
  19. : I've been using a dialing program under Linux that will connect
  20. : to a shell account and do a bunch of intelligent stuff including
  21. : transfer files.  I had been using Zmodem via lrz/lsz with success 
  22. : for a long time, but I'm finding it's just not working anymore, 
  23. : due to the fact that I can only connect to the target machine now 
  24. : via some kind of POP service that uses telnet and is none too
  25. : transparent.  It may even be 7 bit, it's not clear, and I have
  26. : no control over it.
  27. : 
  28. : At any rate, I found that I could manually use kermit to perform
  29. : a successful transfer.  So I figured the obvious thing to do was to
  30. : replace my lrz/lsz logic with C-kermit equivalents.  This worked
  31. : fine but with one problem-- after the transfer finished, C-kermit
  32. : does something that causes a disconnect.  So, I did some research
  33. : on deja/google and found some references to some mention of the
  34. : subject in a documentation file somewhere:
  35. : 
  36. : >Many people want to be able to make a dialout connection with UNIX
  37. : >C-Kermit, but then use some other software on the connection that C-Kermit
  38. : >made.  They quickly find that when they exit from C-Kermit, that the
  39. : >connection is gone before they can start the other application.
  40. : >
  41. : >It is a fundamental property of UNIX that when a process exits, then every
  42. : >file that was opened by that process is automatically closed by UNIX.
  43. : >Closing a terminal device (such as a dialout tty device) hangs it up.
  44. : >There is nothing the process can do about it.
  45. : >
  46. : >However, many workarounds are possible.  Here are just a few:
  47. : >
  48. : > . Read about the REDIRECT command in the ckcker.upd file.
  49. : >
  50. : > . Find out the file descriptor of the open device (it is given by
  51. : >   C-Kermit's \v(ttyfd) variable) and then run ("!") your other program
  52. : >   from the C-Kermit prompt, feeding it the file descriptor, e.g. through
  53. : >   shell redirection or a command line option (the method depends on the
  54. : >   other program, the capabilities of the shell, etc).
  55. : >
  56. : > . After Kermit makes the connection, type "show comm" to find out the
  57. : >   filename of the lock file.  Then suspend Kermit, then delete the lock
  58. : >   file, then start the other program and tell it to open the same tty
  59. : >   device.
  60. : 
  61. : 
  62. : Now my original approach used lrz something like the following:
  63. : 
  64. :     lrz </dev/modem >/dev/modem
  65. : 
  66. : Since this doesn't hang up the line, I presume that the issue is NOT
  67. : "close" of the device.
  68. : 
  69. Right -- it uses the open stdin/stdout file descriptors, which have
  70. been redirected from/to the modem.  Since the lrz program uses stdin/out,
  71. it never opens or closes it.
  72.  
  73. : So I tried serveral things.  I noticed that it is possible to pass in
  74. : an open file descriptor and have kermit use that.  But, I gathered
  75. : you can't just do:
  76. : 
  77. :     kermit -r -i -l 0 </dev/modem
  78. : 
  79. : As this is only open for input, and kermit is going to need bidirectional
  80. : I/O on the FD.
  81. :
  82. Did you try it?
  83.  
  84. : So lastly, I figured ok, let's see if it really is the close of the
  85. : device or something *specific* kermit is doing on exit.  I manually
  86. : invoked kermit so that it wouldn't exit, and instead of doing a "quit"
  87. : after the transfer, I switched to another window and did a kill -9
  88. : on the kermit process.  Voila!  no disconnect occurred.
  89. : 
  90. Because you killed Kermit and it couldn't close the device.  Meanwhile 
  91. another process had it open, right?  That's why you didn't carrier drop
  92. or whatever.
  93.  
  94. : So, I've since implemented a solution to the problem which entails
  95. : a kermit script that does something like this:
  96.  
  97. : set modem none
  98. : set line /dev/modem
  99. : set file type bin
  100. : receive
  101. : !/tmp/killkerm
  102. : 
  103. : 
  104. : And invokes kermit like this:
  105. : 
  106. : echo "kill -9 $$" >/tmp/killkerm
  107. : chmod a+x /tmp/killkerm
  108. : exec kermit -y kermitscript
  109. :
  110. : And it works like a choim.  However, it is a major kludge.
  111. :
  112. Yes indeed.
  113.  
  114. : I'm using
  115. : it because it works, but does anyone know how I can get kermit to NOT
  116. : do whatever it is doing to the device before it exits so I don't have
  117. : use kill?  Perhaps it's doing some kind of rude stty/ioctl that's 
  118. : causing it?
  119. : 
  120. Try the first method (-l 0) and see what happens.  If that doesn't work,
  121. what I'd recommend is to let Kermit handle everything -- dialing, terminal
  122. session, and file transfer.  That's what it's designed for.
  123.  
  124. In any case, let us know what happens and we'll see what to do next.
  125.  
  126. - Frank
  127.